COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.NEWSS PHILOSOPHY AND DESIGN GOALS
C00011 00003	.NEWSSS USE OF A PLANNING MODEL
C00020 00004	.NEWSSS THE RUNTIME SYSTEM
C00027 00005	.NEWSSS PROGRAMMING AIDS
C00030 ENDMK
C⊗;
.NEWSS PHILOSOPHY AND DESIGN GOALS

	A full language for planning manipulatory tasks of the
complexity required for assembly needs many features, some of which
do not exist in any current system.  We have identified the following
interrelated goals. 

.NEWSSS DATA AND CONTROL STRUCTURES

	We believe that the principal mode of input to 'AL should be
textual, as opposed to spoken or manual (joystick).  There are levels
of complexity which are much more readily transmitted from man to
machine through an interface of symbolic text.  Complicated
simultaneous motions of two arms and specifications of termination
and error conditions are more likely to be unambiguously stated
through the medium of text, if for no other reason than the structure
imposed on the textual language forces a consistent framework on
initially less structured intuitive ideas.  Non-textural forms of
input can be a very useful means for defining target locations,
suggesting arm trajectories designed to avoid collisions, and other
purposes of this nature.  We believe, however, that such tools are
most useful when applied in conjunction with a program text which
supplies the skeletal intent of the programmer; to this end 'AL
should facilitate use of such input devices as joysticks and other
positioning tools during the process of programming. 

The supervisor level of 'AL should be simple enough to allow
natural teaching by showing; it should be easy to interface such new
devices as joysticks and simple vocal input into 'AL, although we
do not intend to do so at present.

We want to write entire programs in a natural manner.  The
machine-language aspect of current manipulation languages makes it
cumbersome to write long programs in any structured way.  We want a
language which lends itself to a more systematic and perspicuous
programming style. Algol-like control structures are an
improvement over assembly-like straight code with jumps. 

Experience with languages like SAIL and WAVE has shown that text macros are a
useful feature; they reduce the amount of repetitive
typing.  'AL should have a general-purpose text macro system
interfaced into the scanner and parser. 

The datatypes available should include those types necessary to refer to
one-dimensional measures (like distance, time, mass) and
three-dimensional measures (like directed distance, locations,
orientations). Arithmetic operators should be available not only for
the standard scalar operations like multiplication and addition, but
also for such operations as rotation and translation. 

Simultaneous execution of several processes should be available. A
general mechanism for simultaneity is desired, so that calculation
and arm motion can take place simultaneously, and several
manipulators can be in independent motion. 

.NEWSSS MOTION SPECIFICATIONS

Experience with WAVE has shown that calculating trajectories for
manipulators is a desirable feature, although a time-consuming one. 
Trajectory calculations, together with all other calculations which
need only be performed once, should be done at compile time.  This
allocation of effort can drastically reduce the computing load at
execution time and eliminate wasteful recomputation every time a
sequence of actions is executed.  This leads to a clear distinction
between compile-time and runtime. 

The user should be able to demand that a trajectory pass through
given intermediate points.  The primary use of this is to avoid
collisions during the motion.  It is also useful in specifying
complicated motions. 

A wide range of exceptional conditions can occur during the motion of a
manipulator: excessive force might be exerted, a stopping condition
may be met, the arm might come too close to a dangerous region, the
user may interrupt the motion manually, or some specified time limit
might be exceeded.  Appropriate action must be taken as soon as any
of these occurs, for example: to start up a new concurrent process,
to terminate something already active, to notify the user, to file
away a statistic somewhere in a table.  Therefore, 'AL must allow the
user flexibility in specifying what conditions to monitor during the
course of motions (and during execution of blocks of code in
general), and what to do in the case that a tested condition occurs.
It is also useful to change the nature of the test during a motion,
if different segments of the motion require different types of
monitoring.  This concept can be generalized to include the
modification of a motion during its execution to accomodate to
changing conditions. 

We make the assumption that threshold tests suffice for assembly with
sensory feedback.  In many cases, threshold tests do suffice: To tell
if the arm has hit something, a threshold test on directed force
works. To tell if a screw is binding, a similar test serves.  In
general, however, such tests lack the ability to modify trajectories
on the basis of signal strength.  This lack is only partially filled
by an ability to disable and enable condition monitors during the
course of a motion.  It is our hope eventually to include the
capacity for including devices such as wrist force sensors  and vision in the
servo control loop in a programmable fashion.  When these facinating
prospects are better understood, they will be included in the language. 

.NEWSSS USE OF A PLANNING MODEL

Since locations are not known exactly during the planning of a
trajectory, there should be a clear distinction between planned
values and runtime values.  Planned values will be used for
trajectory calculation; at runtime, trajectories will be modified if
necessary to account for any discrepancies. The planned values are
therefore a database on which trajectory calculations are computed. 
This database will occasionally be referred to as a %4world model%*. 

Assembly tasks require that one object be affixed to another.  We
wish to model this by having a semantic attachment between objects. 
If two objects are affixed, and
one moves, the second one should move accordingly, that
is, its planning value should be properly modified. Thus, the world
model must also include information on attachments of objects, since
they will have an effect on planning values.  The affixment
concept carries over to the runtime system, which does the equivalent
modifications of the actual values.  This saves the user untold
bookkeeping operations to determine where an object is after its base
has been moved. 

More generally, 
the compiler should be able to maintain a wide variety of information
about expected runtime states.  This includes not only object
affixments and variable planning values, as previously mentioned,
but also information like the accuracy within which the planning
value is known, how heavy an object is, how many faces it has on
which it can rest, how wide the fingers of an arm should open to
grasp it.  This information may come from several sources, including
explicit assertions by the user, the output of computer-aided design
programs, and built-in knowledge about the system hardware.  
Therefore, 'AL should have a general framework for representing
such knowledge.

'
In addition to its own internal uses,
AL should provide a number of explicit mechanisms for applying this
information, including simple retrieval of data from the
compile-time model and conditional compilation facilities for producing
substantially different object programs, depending on planning
information.  Such facilities allow the user to write a single piece
of code in some generality, while avoiding the inefficiencies of many
needless runtime checks and the planning of useless trajectories for
cases that will never be executed. 

.NEWSSS USE OF DOMAIN-SPECIFIC KNOWLEDGE

The system should have enough domain-specific knowledge to allow
programs to be written in terms of common assembly operations, rather
than exclusively in terms of detailed single motions.  At the
simplest level, this involves provision of a library of common
assembly "macro-operations" that can be conditionally expanded to
perform particular subtasks.  Beyond this, we would like an
interactive system that can take a "high level" description of an
assembly algorithm and fill in many of the detailed decisions
required to produce a consistent and efficient output program.  

The range of decisions required to convert from a high level
description to an efficient output program is quite broad, and many
of the processes involved cannot be modelled readily in terms of the
purely local mechanisms used in expanding library routines.  For
instance, a command like "put the engine block on the table in an
upright position" might require the system to examine future
operations on the engine block to select the best orientation to
use.  Similarly, many operations produce side effects that make other
tasks either easier or harder.  For instance, inserting a pin into a
hole yields information about the exact location of the hole and
therefore of the object into which the hole has been drilled.  If
there are a number of pins to be inserted, then it may be a good idea
to insert pins into the easier-to-locate holes first and then to use
the information so gained to help with the remaining insertions. (On
the other hand, such an ordering may very well make the actual
insertions more difficult because of obstructions to the hand). The
system should be familiar with such considerations and use them
as it generates the output program.  

A user should be able to specify different parts of a task at various
levels of detail.  The system must be able to accept explicit advice
telling exactly how some particular subtask is to be accomplished and
then complete the program in a way that does not conflict with those
things that have been explicitly specified.  This is especially
important for early versions of 'AL, which are not likely to be very
"smart" and will therefore require a fair amount of explicit help. 

The user should be able to describe the "intent" of a particular
piece of code, at least to the extent of specifying any (non-obvious)
prerequisites or updates to the world model.  This facility is
especially important for programs that mix both high and low-level
primitives. Similarly, the system should be able to show the user how
it is filling in the details to produce an output program, and why. 
This is very important both for debugging and for explaining to the
user any requests for advice that it must make. 

.NEWSSS THE RUNTIME SYSTEM

The calculation of trajectories is time-consuming but not
time-critical; servoing of devices is time-critical but not
especially time-consuming.  For efficient code generation,
modification, documentation, and execution, we will write the
compiler in a high-level language and develop and run it under
time-sharing.  The runtime programs will be written in either machine
language or one of the new systems implementation languages (for
example, BLISS), since time-efficient code must be generated.  As one
execution computer will be required for each work station in a
factory, and as the runtime code and its memory requirements will be
quite small, we will write the runtime system for a minicomputer.
The compiler could also be written for the small computer, but this
would compound the problems of writing the compiler; the
computational requirements are much higher during compilation than
execution, so implementing the comiler on the mini would necessitate
either an overly large minicomputer or an overly slow compiler. 

The runtime system must support simultaneous executions of many
processes.  Several manipulators 
or devices
might be running simultaneously, and each
motor requires a separate process; several condition
monitors might be active; several code segments (doing, perhaps,
calculations) might be simultaneously active.  Those processes which
are dealing with real-time devices (joint servos and condition
checkers) must be guaranteed service at regular intervals; the
computation processes can fill in any time gaps.  Thus, the runtime
system must include some simple implementation of multiple processes
under real-time constraints. 

Trajectories are calculated by the compiler on the basis of
incomplete information.  At runtime, it is necessary to modify those
plans to fit them to the somewhat different actual location of
objects.  That means that certain information must be carried at
runtime, specifically the locations that each trajectory is desired
to pass through, the locations of all objects, and how they are
attached together. 

The system must be capable of using vision and other currently
unimplemented forms of feedback. Vision would be quite usefuil in
searching for objects and testing for adequacy of assembly. It is
conceivable that vision will be used for the servoing of an arm; this
implies that vision would be in the feedback loop during motions. Other
dynamic feedback (like force-sensing wrists) could make the
capabilities of the arms much greater in dealing with non-rigid
materials like cloth or rope.  What is needed is a way of specifying
these "external" devices so that when they become available,
they can be meshed into the system without much difficulty. 

The wide range of conceivable tasks implies that pure hardware
servoing will not in general suffice.  The reason for this is that
hardware servoing restricts use to one of a small number of servo
modes (typically position, velocity, or force), and has no provision
for motions of accomodation or motions whose modes might change in
midstream due to some software-detectable condition.  Pure hardware
servoing could not be readily modified to account for new feedback
devices or methods.  A philosophy of %4software servoing%* has these
advantages: It is possible to program the manner in which feedback is
to be used, to interface new types of sensors, 
to modify the servo while the arm is in motion,
to supply the driving program with information concerning
the success of the motion as well as to keep it up-to-date on the arm
status.  Some clearly distinguishable modes of servoing could be
translated into hardware; however, the hardware becomes complicated if
the computer needs to be able to switch modes while the program is being
executed. There would not be much saving in compute power since the
computer would need to perform a servo calculation in order to understand
what the manipulator is doing and to interact with the task. 

.NEWSSS PROGRAMMING AIDS

A user should be able to write a piece of code,  try
it on the spot, and delete or replace sections of previous code.

The compiler should make a great number of semantic checks,
such as assuring that a proposed motion will not hit some object
(although this is a difficult problem which has not yet been
satisfactorily solved)  or that simultaneous independent motions are
not being requested for the same device.

'AL should eventually include non-textual aids to programming.  For
example, joysticks might be used to position heavy manipulators prior
to reading their locations and using them in a program. Graphical
display could be used to to demonstrate the planned locations of
objects and how this changes during the course of the program. 

Error recovery facilities are very important.  A user should be
able to recover from errors discovered during any phase of debugging.
Similarly, production programs should be able to request operator
intervention where necessary and should (at least) be able to be
restarted at a convenient place after the problem is fixed.

There should be a way to investigate the contents of the runtime
system, both variables and code,  in order to patch simple mistakes
discovered during the course of a production run.  This
feature will be especially useful for debugging the compiler.